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Beschreibung 

Datenhaltungssystem fur persistente Daten 

5 Die Erfindung betrifft ein Datenhaltungssystem fur persi- 
stente Daten, 

Embedded (gekapselte) Systeme zur Steuerung von elektroni- 
schen Geraten mussen eine hohe Zuverlassigkeit aufweisen. 

10 Ihre Antwortzeiten auf von auJien zugefuhrte Anweisungen 

mussen in der Kegel sehr kurz sein, Sie unterliegen meist 
auch strengen Hardwarebeschrankungen , Um die Datenintegritat 
zu gewahrleisten, mussen die Daten stromausf allsicher 
(persistent) gespeichert werden. Es ist daher erf orderlich, 

15 entsprechende Datenhaltungssysteme mit permanenten Speichern. 
einzusetzen . 

Die Verwendung von Festplattenspeichern ist aus Zuverlassig- 
keitsgrunden wegen ihrer relativ kurzen Lebensdauer und der 
2 0 Empf indlichkeit gegenuber Temperaturschwankungen problema- 
tisch. 

Aufgabe der Erfindung ist es daher, ein Datenhaltungssystem 
anzugeben, das die vorstehenden Anf orderungen erfiillt und 

25 daruber hinaus zuverlassiger und auch kostengiinstiger zu 

^ realisieren ist. 

Diese Aufgabe wird durch das in Anspruch 1 angegebene Daten- 
haltungssystem gelost . 

30 

Vorteilhafte Weiterbildungen der Erfindung sind in den 
Unteranspriichen angegeben . 

Der wesentliche Vorteil der Erfindung liegt im Zusammenwirken 
35 eines schnellen Zwischenspeichers mit einem nur langsam zu 

beschreibenden permanenten Speicher, Hierdurch konnen Anwei- 
sungen sehr rasch in den Zwischenspeicher ubernommen werden 
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und hierdurch die Antwortzeiten kurz gehalten werden, wahrend 
unabhangig von diesem ProzeB das Einschreiben von Daten vom 
Zwischenspeicher in den permanenten Speicher erfolgt. 

Vorteilhaft ist die Verwendung von Flash-EPROMS (FEPROM - 
Flash Eraseable Programmable Memory) als persistenten Spei- 
cher, die mit geringem Schaltungsaufwand beschrieben werden 
konnen. Die Verwendung von zwei FEPROM-Bausteinen oder zwei 
Speicherbereichen eines FEPROMS-Speichers , in die abwech- 
selnd samtliche notwendige Daten eingeschrieben werden, 
bietet entscheidende Vorteile fur einen Neustart des Systems. 
Bei einem Fehler wahrend des Schreibvorganges - im krassesten 
Fall durch Stromausfall - steht der bisher giiltige komplette 
Datensatz im anderen Speicherbereich zur Verfiigung. 

Zur Verringerung der zu speichernden Datenmenge werden nur 
die fur die Konf iguration notwendigen Daten persistent 
gespeichert. 

Das Datenhaltungssystem ist besonders filr die Konf iguration 
von elektronischen Geraten, beispielsweise Datenterminals 
geeignet . 

Im Storungsfall oder bei einem gewollten Wiederanlauf 
(Restart) werden aus den persistent gespeicherten Daten mit 
Hilfe von ebenfalls persistent gespeicherten Programmen alle 
notwendigen Daten der Applikation zur Festlegung der Termi- 
nalkonfiguration rekonstruiert - oder bei sehr einfachen 
Datenhaltungssystemen direkt iibernommen. 

Vorteilhaft ist auch die Moglichkeit, eine oder mehrere 
Konfigurationen auf der Datenseite vorzubereiten und diese 
erst zu einen spateren Zeitpunkt durchzuf iihren . 

Ein Ausfilhrungsbeispiel der Erfindung wird anhand von Figuren 
naher erlautert. 
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Es zeigen: 

Figur 1 ein elektronisches Terminal mit dem 

er f indungsgemafien Datenhaltungs system, 
5 Figur 2 ein Prinzipschaltbild des Datenhaltungssystem, 

Figur 3 ein Prinzipschaltbild zur Erlauterung des 
Systemneus tarts und 

Figur 4 ein Hardwarezustandsdiagramm. 

10 In Figur 1 ist als Beispiel fur den Einsatz des erfindungs- 
gemaiien Datenhaltungssystem ein elektronischen Terminals T 
als Blockschaltbild dargestellt. Bei diesem Terminal handelt 
H es sich um einen synchronen Multiplexer, der uber eine erste 
Datenverbindung LI und eine zweite Datenverbindung L2 mit 

15 anderen Terminals bidirektional Daten austauscht. Ober 

Anschlulibaugruppen (Terminal-Cards) TCI und TC2 werden diese 
Daten uber ein Koppelfeld CC geftihrt, das einzelne bidirek- 
tionale Datenkanale DKl bis DKn aus den externen Datenstromen 
abzweigt und hinzufugt. Aulierdem konnen die Datenkanale im 

20 Koppelfeld neu geordnet werden, bevor sie vom Terminal 
weitergesendet werden. 

Die Konf iguration (Arbeitsweise) des Koppelfeldes bestimmt 
beispielsweise, welche Kanale abgezweigt werden. Dessen 
Konf iguration und die Funktion der Anschlulibaugruppen werden 
von einer Systemsteuerung SCU bestimmt, die ihre Anweisungen 
liber eine Datenverbindung DV von einer Zentralsteuerung ZCU 
erhalt, Deren Anweisungen (Befehle) werden von der System- 
steuerung umgesetzt und in konvertierter Form als Steuerin- 
30 formation SI an die Baugruppen des Terminals weitergegeben, 
wo die (hardwaremaiJige) Konf iguration erf olgt , 

Von den Baugruppen des Terminals werden Alarm- und Zustands- 
meldungen MI an die Systemsteuerung weitergegeben, die diese 
35 umsetzt und zur Zentralsteuerung weiterleitet oder ggf- bei- 
spielsweise selbst Ersatzschaltungen vornimmt. 
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Damit bei einem Stromausf all die vorher eingestellte Konfigu- 
ration wieder hergestellt werden kann, miissen alle fur die 
Konfiguration notwendigen Daten, hier als Konf igurationsdaten 
bezeichnet, in einem persistenten Datenhaltungssystem PDB 
abgespeichert werden. 

In Figur 2 ist das persistente Datenhaltungssystem PDB als 
Prinzipschaltbild dargestellt. Alle Konf igurationsdaten sind 
in einem ersten Speicher STl, einem Schreib-Lese-Speicher 
(Random Access Memory) RAM, gespeichert; beispielsweise in 
Form eines sogenannten Obj ektmodells . Ein solches Objekt- 
modell beinhaltet sowohl funktionelle als auch hier zur Kon- 
figuration des Terminals dienende persistente Daten 
(Konfigurationsdaten) , die als MIB - Management Information 
Base - bezeichnet werden. 

Bei einer Neukonf iguration, in Figur 2 durch eine Befehls- 
sequenz NKON ausgelost, werden zunachst die Konfigurations- 
daten im ersten Speicher STl geandert und in die Steuerinfor- 
mation SI umgesetzt an die betroffenen Baugruppen gesendet, 
wo die hardwaremaiiige Konfiguration erfolgt. 

Das Einschreiben der Daten in den persistenten Speicher 
erfolgt in mehreren Abschnitten in einem Hintergrundprozefi, 
dem Speicherprozefi SPR, dessen Wirkungsbereich in Figur 2 
angegeben ist. 

Das Datenhaltungssystem sorgt dafUr, daJJ die im ersten 
Speicher STl als Objektmodell gespeicherten Konfigurations- 
daten gegebenenfalls inklusive Rekonstruktionsdaten als 
Stream (Datensequenz ) unter Verzicht auf vorgegebene feste 
Speicherbereiche platzsparend in einen Zwischenspeicher ZST 
eingespeichert werden. Danach kann die durchgef uhrte Trans- 
aktion, beispielsweise eine Neukonf iguration des Terminals, 
bestatigt werden und eine weitere Transaktion durchgefUhrt 
werden . 
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Der Zwischenspeicher wird aus mindestens zwei funktionell in 
Serie geschalteten Schreib-Lese-Speichern RAMI und RAM2 bzw. 
zwei Speicherbereichen eines RAM-Speichers gebildet, die im 
folgenden auch als Speicher bezeichnet werden. In den zweiten 
Schreib-Lese-Speicher werden die in den ersten Schreib-Lese- 
Speicher eingespeicherten Daten - gesteuert von einer 
Speicherverwaltung - ubernomitien, so dali der erste Schreib- 
Lese-Speicher RAMI fur die Neueinspeicherung von Daten einer 
weiteren Konf igurationen zur Verfugung steht. Die im zweiten 
Schreib-Lese-Speicher RAM2 gespeicherten Daten konnen nun in 
einen persistenten Speicher PST eingeschrieben werden. 

Als persistenter Speicher sind zwei Flash-EPROMS : FEPROMl und 
FEPR0M2 bzw. zwei Speicherbereiche eines groBeren Speichers 
vorgesehen. Bei kleineren Datenmengen ist es auch denkbar, - 
unterschiedliche Speicherbereiche eines FEPROM-Bausteins zu 
verwenden. 

Das Abspeichern jeweils aller persistenten Daten - MIB - 
erfolgt alternierend im ersten und zweiten FEPROM bzw. 
Speicherbereich. Bei grofieren Datenmengen ist es sinnvoll, 
nur geanderte Daten in die betroffenen Segmente (z.B. 
64kBytes) des persistenten Speicher zu kopieren, 

Zwar erfordert das Einschreiben von Daten in die FEPROM einen 
relativ groBen Zeitaufwand, der jedoch durch die Zwischen- 
speicherung unkritisch ist, da durch das Kopieren der persi- 
stenten Daten MIB in den Zwischenspeicher die unterschied- 
lichen Prozesse zeitlich entkoppelt sind. 

Je mehr ,,Speicherstuf en" der Zwischenspeicher aufweist, desto 
mehr kurz auf einanderf olgende Konf igurationen konnen 
zwischengespeichert werden und daher bei einem gewollten 
Neustarten des Systems rekonstruiert werden. 
Wenn es wahrend des Einschreibens zu einem Stromausfall 
kommt, gehen zwar die noch nicht in den Festspeicher PST 
eingeschriebenen Daten MIB verloren - der bisher die Konfigu- 
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ration bestimmende Datensatz, die vorhergehende persistent 
gespeicherte MIB, ist jedoch iininer in dem anderen FEPROM 
vorhanden, so dai3 eine gultige Konf iguration rekonstruiert 
werden kann. 

Anhand von Figur 3 soil ein Neustart nach einem Stromausf all 
naher erlautert werden. Der Neustart erfolgt mit Hilfe eines 
Startprogrammes STP, das in einem persistenten Programm- 
speicher PRST gespeichert ist. Durch das Startprogramm wird 
zunachst eine ebenfalls persistent gespeichert Applikations- 
software inklusive der Datenbanksof tware in den ersten 
Speicher STl .geladend), (2), AnschlieJiend wird und ein voll- 
standiger Satz persistenter Daten MIB wird aus einem der 
FEPROMS in den RAMI geladen ( 3 ) , ( 4 ) , um schnellere Zugriffs- 
moglichkelten zu haben, Danach erfolgt auf Anforderung (5) 
programmgesteuert die automatische Rekonstruktion (6) der 
Konfigurationsdaten in der Applikation durch das Datenhal- 
tungssystem, so daJi ein ablauf f ahiges Programm wiederherge- 
stellt wird. 

In den Figuren 2 und 3 sind keine Recheneinheiten darge- 
stellt. Ihre Funktionen sind durch den nur den persistenten 
Speicher betreffenden Speicherprozefi SPR und die den ersten 
Speicher umfassenden Applikationsprozesse APR symbolisiert . 

Bei einem. von der Zentralsteuerung oder Systemsteuerung soft- 
waremaiiig ausgelosten neuen Systemhochlauf loscht das 
Betriebssystem den Inhalt des ersten Speichers STl. Der 
Inhalt des Zwischenspeichers bleibt jedoch erhalten, so daii 
gleich mit der Rekonstruktion aus dem Zwischenspeicher begon- 
nen werden kann. 

In sehr einfachen Datenbanken konnen die Daten des ersten 
Speichers STl auch direkt in den Zwischenspeicher ZST und den 
persistenten , Speicher PST libernommen werden. 
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Bei unkritischen Zeitbedingungen kann der Zwischenspeicher 
auch aus nur einem Schreib-Lese-Speicher bestehen. 

In Figur 4 sind die Hardwarezustande einer Baugruppe darge- 
stellt. Oberhalb des waagerechten Striches stimmt der daten- 
mafiig vorgegebene Konf igurationsstand (S) mit deiri aktuellen 
(hardwaremaiiig) realisierten Konf igurationsstand (H) uberein. 
So kann bei einer Neukonf iguration (1) der Konf igurations- 
stand A direkt in den Konf igurationsstand B uberfuhrt werden. 
Der Konf igurationsstand B kann jedoch auch in einem Schritt 
(2) in den inaktiven Konf igurationsstand ubernoimnen werden. 
Hier kann der datenmaBige Zustand - mit B bzw. SB (S - Soft- 
ware) bezeichnet - in einem weiten Schritt von B in C und 
weiter (6) in D geandert werden, wodurch jedoch noch keine 
Anderung der tatsachlichen (hardwaremaiiigen) Konf iguration 
erfolgt - mit HA, HB, HC bezeichnet, Der Anwender kann im 
inaktiven Zustand von SC/HB aus entweder in den frtiheren 
Konf igurationszustand B (Rlickfallkonf iguration) durch Schritt 
(4) gelangen, oder den neuen Konf igurationszustand C in einem 
Schritt (5) erreichen. 

Entsprechendes gilt fiir den datenmaiiigen Zustand SD, von dem 
aus. wieder (7) die Ruckfallkonf iguration B oder in einem 
Schritt (8) der entsprechende Hardwarezustand HD erreicht 
werden kann. Die Ruckfallkonf iguration wird im inaktiven 
Konf igurationszustand im Schreib-Lese-Speicher RAM2 gespei- 
chert. 

Weitere Einzelheiten der Erfindung sind dem beigefiigten 
Bericht, Seiten 8 bis 22, zu entnehmen. 
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1 Einleitung 



Embedded Systeme gewahrleisten in der Regel ohne Eingriff von auBen eine sehr hohe 
Zuverlassigkeit. Ihre Antwortzeiten sind sehr kurz und sie unterliegen strengen 
Ressourcenbeschrankungen bezuglich RAM und persistenter Speichennedien. Selbst ein 
temporarer Spannungsausfall kann behandelt werden, da seine Daten stromausfallsicher 
gespeichert werden. Um die Datenintegritat zu gewahrleisten, muB in einem Embedded 
System ein geeignetes Datenbanksystem eingesetzt werden. 

In den folgenden Kapiteln wird das objektorientierte Datenhaltungssystem, DBControl, 
vorgestellt. DBControl wurde bei der Firma Siemens als Klassenbibliothek in C++ 
entwickelt. Es realisiert die Persistenz, dh. die stromausfallsichere Datenhaltung eines 
Synchronen Multiplexers fiir die Telekommunikation in Festnetzen. Das Gerat arbeitet mit 32 
MB RAM sowie 2 MB Flash-EPROM (FEPROM) als persistentes Speicherinedium unter 
dem Betriebsystem Lynx OS. 

Als erstes zeigen wir die Grunde fur die Entwicklung dieses Datenfaaltungssystems imd 
warum sich eine kaufliche Datenbank nicht so geeignet ist. AnschlieBend erortem wir das 
Design von DBControl, der objektorientierten Klassenbibliothek fur Persistenz. Der 
Schwerpunkt liegt bei diesem Thema auf der C++-technischen Realisierung. Daruberhinaus 
werden wir ims mit der Frage beschaftigen, wie die Daten in ein persistentes 
Speichermedium, das FEPROM, abgebildet werden. Diese Diskussion umfaBt ein 
prozeBubergreifendes Transaktionskonzept, das Zeitverhalten von Transaktionen und die 
Anbindung des FEPROMs. AuBerdem werden die bei DBControl eingebauten 
Sicherheitsmechanismen erlautert. Hier wird das Anlaufverhalten eines Embedded Systems 
bezuglich seiner Datenbank vorgestellt. 



2 Eigenschaften eines Embedded Systems 

Die Anforderungen eines Embedded Systems an ein Datenhaltungssystem werden am 
Beispiel des Synchronen Multiplexers naher beleuchtet 

Der Synchrone Multiplexer halt seine gesamte Konfiguration in einem C++-Objektmodell. 
Wird der Multiplexer uber eine Steuerschnittstelle von auBen neu konfiguriert, so wird sein 
Objektmodell entsprechend geandert. AnschlieBend gibt er die Daten in konvertierter Form 
an eine periphere Hardware weiter, die die eigentliche Steuerung ubemimmt. Damit der 
Multiplexer bei einem Stromausfall dieselbe Konfiguration wieder herstellen kann, muB das 
Objektmodell persistent abgespeichert werden. Dazu ist ein prozeBubergreifender 
Transaktionsmechanismus notwendig, weil die Objekte uber mehrere Prozesse verteilt sind. 
Als persistentes Speichermediiun wurde fiir den Multiplexer ein FEPROM ausgewahlt. Das 
ist in einem Embedded System robuster imd auBerdem kostengunstiger als eine Festplatte. 
Die Zugriffsmechanismen des Datenhaltungssystems mussen an das FEPROM angepaBt sein. 
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3 Auswahl einer geeigneten Datenbank 

Dies hat groBe Auswirkungen auf die Auswahl eines Datenhaltimgssystems. Die Datenbank 
muB komplett im RAM laufen und darf dort nicht viel Platz in Anspruch nehmen, weil das 
gesamte Embedded System mit 32 MB RAM fiir Programm- und Datenbereich auskonunen 
mufl. Die Datenbank mufi auBerdem die Mechanismen zum Beschreiben von FEPROMs 
unterstiitzen. Dabei muB das geforderte Zeitverhalten von einer Transaktion pro Sekunde 
beriicksichtigt werden. 

Eine kaufliche Datenbank bietet einen wesentlich grGBeren Funktionsumfang, der in 
Embedded Systemen nicht benotigt wird. Beispielsweise die Untersttitzung von verteilten 
Datenbanken oder die SQL-Schnittstelle sind im Runtime-System der meisten Datenbanken 
enthalten. Derartige komplexe Konzepte lassen sich auch nicht herausnehmen. Aufgrund der 
Ressourcenbeschrankimg von Embedded Systemen ist hier eine so machtige Datenbank nicht 
einsetzbar. 

In Abbildung 1 sind die Anforderungen an das Datenhaltimgssystem eines Embedded Systems 
und seine technischen Merkmale zusammengefaBt. Aus diesen Vorgaben ist die 
f Klassenbibliothek DBControl entstanden, die genau die geforderten Features realisiert und 
dessen CodegroBe sehr kompakt ist. 



Anforderungen fur Embedded System e: 

O Transaktionmechanismus 

O Datenintegritat 

O MuhiprozeBfahigkeit 

O Funktionalitat abgestimmt auf Embedded System 
O Unterstiitzung von FEPROMs 




Technbche Merkmale: 

O Stabiler und perfomnanter Persistenzmechanismus 
O Kompakte Anwenderschnittstelle in C-H- 
O Transaktionszeiten < 1 sec 
O GroBe der Library 87 KByte 



Abbildung 1: Merkmale und Anforderungen des Datenhaltungssystems fiir Embedded Systeme 
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Seiteit^^2, . 

4 Streammechanismen fur Persistenz genutzt 

Eine zentrale Aufgabe des Datenhaltungssystems ist die persistente Abspeicherung von C++- 
Objekten sowie der Beziehungen zwischen ihnen. In DBControl wird diese Aufgabe mit Hilfe 
von Streammechanismen realisiert. Fur die Einbindung dieser Mechanismen benutzt das 
Datenhaltungssystem die Klassenbibliothek Tools.h++ von Rogue Wave [1]. Hier werden 
samtliche persistente Attribute eines Objektes nacheinander in einen bestimmten 
Speicherbereich kopiert und von dort beim Aufbau der Objekte wieder gelesen. 

Tools.h++ bietet zu diesem Zweck die Klasse RWCollectable an. RWCoUectable propagiert 
die virtuellen Methoden saveGuts() fur die Abspeicherung und restoreGutsQ fur das Lesen der 
persistenten Attribute (siehe Bild 2). Jede Klasse, die persistente Attribute hat, wird von 
RWCollectable abgeleitet. Sie redefiniert die Methoden saveGuts() und restoreGutsf) 
folgendennaBen: 

Die Methoden saveGutsQ und restoreGuts() haben einen Stream-Pointer als Parameter. Die 
persistenten Attribute eines Objektes werden nun mit Hilfe vOn Output- beziehungsweise 
Input-Operatoren auf diesen Stream geschrieben oder oder von ihm gelesen. Transiente 
Attribute werden nicht aufgelistet und dadurch auch nicht abgespeichert. 

Mit diesem Mechanismus kdnnen Attribute mehrerer Objekte nacheinander in einem Stream 
geschrieben werden. Um eine C++-Klasse eindeutig zu identifizieren, wird jeweils eine 
Classid als emdeutige Nummer mit abgespeichert. Durch sie wird beim Auslesen der Daten 
entschieden, welches Objekt im Augenblick rekonstruiert wird. Fur dieses Objekt wird erst 
der Default-Constructor und anschlieBend die restoreGuts()-Methode aufgerufen. Auf diese 
Weise werden nach und nach alle abgespeicherten Objekte aus einem Stream erzeugt und 
initialisiert 



5 Clustering von C-H--Obiekten 

Beim Abspeichem gilt die Regel, daB samtliche Objekte eines Sj^eams neu geschrieben 
werden mussen, wenn sich ein Objekt innerhalb des Streams andert Das'liegt daran daB kein 
direkter Zugriff auf einzelne Attribute oder Objekte auf dem Stream mOglich ist. Alle 
Attribute werden nacheinander auf dem Stream geschrieben, die genaue Position eines 
Objektes und dessen Attribute ist aber nicht bekannt. 

Um ein ganzes Objektmodell persistent zu speichem und anschlieBend wieder zu 
rekonstruieren, genugt es nicht, die Attribute der Objekte abzuspeichem. Beziehungen 
zwischen den Objekten sind ebenfalls wichtige Informationen, die persistent abgespeichert 
werden mOssen. DBControl unterstutzt das Speichem von Pointem zwischen Objekten 
innerhalb ernes Streams. Streamubergreifende Pointer konnen nicht gespeichert werden. 

Daraus ergibt sich folgende einfache Regel fur das Clustering der Objekte zu einzelnen 
Streams: Objekte, zwischen denen persistente Beziehungen existieren, mOssen innerhalb 
ernes Streams abgespeichert werden. Andererseits sollten nicht zu viele Objekte einem 
Stream zugeordnet werden, da sonst das Schreiben des Streams bei Anderung eines Objektes 
zu lange dauert. 
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6 Design des Persistenz-Konzepts 

Abbildung 2 zeigt das Design von DBControl [3]; Die Klasse DBContainer dient als 
Platzhalter fur Streams, indem jeweils ein DBContainer-Objekt genau einen Stream 
reprasentiert. Die Klasse DBCoIlectable, abgeleitet von RWCoUectable, ist die Vaterklasse 
aller persistenten Applikationsklassen. Sie vererbt die Methoden saveGuts() und restoreGuts() 
zum Abspeichem und Initialisieren persistenter Attribute. DBContainer halten einen oder 
mehrere Pointer auf DBCollectables imd bestinmien damit die Zugehorigkeit der Objekte zu 
genau einem Stream. DBManagerlmpl halt mehrere DBContainer-Objekte. 



RWCoUectable 



saveGutsQ 
restoreGutsO 



DBManagerlmpl 



DBCoIlectable 



■o 



DBContainer 



saveO 
restoreO 
insertObjO 
renoveObj 



I ApplicationClass 



I saveGutsO 
i restoreGutsO 



□ Klasse 

^ Vererbung 

O Containment 
—0 Assoziation (null to many) 

Abbildimg 2: Klassendesign von DBControl 

Analog dazu konnen mehrere Streams erzeugt werden. Abbildung 3 zeigt das Layout der 
Datenbank. Das Layout ist durch die Anzahl und GroBe der Streams genau dimensioniert. EHe 
Tabelle DBTable halt samtliche Verwaltungsinformationen uber die einzelnen Streams: Es 
werden Lange, Anfangspointer und Validflag - d.h, ob der Stream in Verwendung ist - in 
dieser Tabelle gespeichert. 



DBTable 



DBContainer / Streaml 



DBContainer / Stream 2 



DBContainer / Stream n 




Statische 
DBContainer 
fiir Streams 



Abbildung 3: Layout der Datenbank 
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Die Klasse DBManager bildet die Schnittstellenklasse des Datenbanksystems zur Applikation 
(siehe Abbildung 4). Nach dem Bridge-Konzept von Gamma [2] separiert sie das exportierte 

aS^/'''' i^^^^^ri Implementierung, die in DBManagerlmpl und den anderen Klassen 
m Abbildung 2 enthalten ist. Der Vorteil dieses Designkonzepts besteht darin, dafi die interne 
Implementierung in einer Library zusammengefaBt wird. Diese Library kann in der 
taplementierungs. und Testphase beliebig oft ausgetauscht werden, ohne daU die Applikation 
deshalb neu ubersetzt werden muB, Solange sich die Schnittstelle, dh. die Headerdatei der 
Klasse DBManager nicht andert, muB die Applikation bei einer neuen Version der Library 
ledighch neu gelinkt werden. Bei Verwendung einer Shared Library ist sogar nur ein Neustart 
der Applikation notwendig. 



DBManager 



theDBMgrImpl::void* 



initO 
commhO 

createContainer( DBContainerld ) 
deIeteContainer( DBContainerld ) 
modifyContainer( DBContainerld ) 
r^terObj( DBColiectable*, DBContainerld ) 
unregisterObj( DBCoUectable*, DBContainerld ) 



O- 



DBManagerlm pi 



initO 
commitO 

createContain^ DBContainerld ) 
deleteContainef( DBContainerld ) 
nK>difyContainer( DBContainerld ) 
registMObj( DBCoUectaWe*. DBContainerld ) 
unregisterObj( DBCoUectable*, DBContainerld ) 



Abbildung 4: Interface von DBControl nach dem Bridge Concept von Ganuna 



6.1 Die Klasse DBMa nager ab Schnittstelle zur Anplikartnn 

In der Klasse DBManager sind samtliche Funktionen des Datenbank-Systems ftr den 
Anwender veiftg.ar: createContainer() und deleteContainer() dienen dem Erzeugen und 
^^^^ r° f^'^T'^l^.'T^ zugehdrigen Streams. Beim Erzeugen eines Streams wird 
Tne nu^°" (siehe Abbildung 3) ein unbenutzter Stream herausgesucht Sein Pointer wird 
Zt^Tr. 2^C°^tamer-Objekt gespeichert. deleteContainer() gibt diesen Speicherbereich 
wieder frei und loscht das DBContainer-Objekt. 

Durch registerObjO wird ein Applikationsobjekt in einem bestimmten DBContainer 
registnert. Im DBContainer wird die Methode insertObj() aufgerufen und der Pointer auf 
dieses Objekt wird gespeichert Ab diesem Zeitpunkt ist dieses Objekt genau dem 
DBContainer zugeordnet Durch unregisteiObj() wird das Objekt wieder aus dem 
DBContainer ausgetragen. 

Wahrend einer Transaktion markiert die Applikation diejenigen DBContainer durch Aufruf 
von modifyContainer(), deren Daten sich geandert haben. Am Ende der Transaktion werden 
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die geanderten DBContainer durch Aufruf von commit() in den vorgegebenen 
Speicherbereich gestreamt. Dabei wird die Methode save() bei der Klasse DBContainer 
aufgerufen. Sie streamt samtliche Objekte, die in dem DBContainer registriert sind, durch 
Aufruf von saveGuts(). 

Im Gegensatz zum commit() wird beim Aufruf von init() das gesamte Objektmodell aus den 
Streams ausgelesen und aufgebaut. Es werden nacheinander samtliche Streams im 
Datenbank-Layout (siehe Bild 3) auf Gultigkeit uberpriifl. Enthalten sie gultige Daten, so 
wird ein DBContainer erzeugt. In der Methode restore() der Klasse DBContainer werden die 
Applikationsobjekte erzeugt und ihre Attribute mit Hilfe von restoreGuts() aus dem Stream 
initialisiert. 

In Abbildung 5 ist das gesamte Objektmodell, wie es beispielsweise bei der Initialisierung aus 
den Streams erzeugt vsdrd, zu sehen. Das Objekt DBManagerlmpl halt mehrere DBContainer, 
die wiederum Pointer zu einem oder mehreren persistenten Applikationsobjekten hahen. Die 
Applikationsobjekte eines DBContainers sind teilweise miteinander verpointert. Persistente 
Beziehungen zv/ischen Objekten unterschiedlicher DBContainer gibt es nicht. 




zwischen Objekten 



Abbildung 5: Typisches persistentes Objektmodell eines Applikationsprozesses 
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7 ProzeBu bergreifende Transaktionssteueniiiff 

Werden durch eine Konfiguration die persistenten Daten einer Applikation verSndert so wird 
dies in emer sogenannten Transaktion behandelt. Eine Transaktion besteht aus einer 
Ausflihnmgsphase und der Commit-Phase. in der die Datenbank aktualisiert wird In einer 
Embedded Software mit verteilter ProzeBarchitektur muB eine Tj^pgaktion und deren 

konununiiieren dabei mittels 



O Commit-Phase der Transaktion ^ Ausfiihrungsphase der Transaktion 

AbbiiduDg 6: Die prozeBQbergreifende Transaktionssteuening in DBControl 
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Abbildung 6 zeigt Schritt fur Schritt wie DBControl eine prozeBubergreifende Transaktion 
steuert. Im Beispiel ist ProzeB 1 fur die Transaktion verantwortlich, da sie uber ihn getriggert 
wird (Schritt 1). In der Ausfuhrungsphase (Schritt 2-7) werden in beiden Prozessen 
persistente Daten geandert. Jede diese Anderung wird DBControl uber sein Persistenz- 
Interface mitgeteih (Schritt 2 und 5). Als Folge davon vermerkt DBControl den ProzeB im 
SharedMemory mit einen eindeutigen ProzeBIdentifier (Schritt 3 und 6). Am Ende der 
Ausfiihnmgsphase geht die KontroUe an die Applikation in ProzeB 1 zuruck. 

Die Commitphase wird durch den transaktionsverantwortlichen ProzeB, im Beispiel ProzeB 1, 
angestoBen (Schritt 8). Da ProzeB 1 im SharedMemory gekennzeichnet ist (Schritt 9), wird 
mittels des Persistenzmechanismus die Datenbank aktuahsiert (Schritt 10). Der zugehdrige 
ProzeBIdentifier wird aus dem SharedMemory entfemt. DBControl identifiziert im 
SharedMemory ProzeB 2 als nachsten Kandidaten fiir den Commit DBControl in 
ProzeB 1 schickt DBControl in ProzeB 2 eine Nachricht, die Datenbank zu aktualisieren 
(Schritt 11). Im ProzeB 2 wird gleichfalls die Datenbank aktualisiert und der ProzeBIdentifier 
geloscht (Schritt 12 xmd 13). Am Ende des Conmiits wird die KontroUe an die Applikation 
des transaktionsverantwortlichen Prozesses, ProzeB 1, zunickgegeben (Schritt 14). Die 
Datenbank ist konsistent und die Transaktion abgeschlossen. 

8 Speichermedien fur die Verwaltung der persistenten Daten 

DBControl verwendet verschiedene Speichermedien fur die Abspeicherung der Datenbank 
(siehe Abbildung 7). Im RAM wird die Datenbank durch das persistente Objektmodell der 
Applikationsoftware prasentiert. Dies wird im Falle eines softwaretechnisch ausgelosten 
Systemshochlauf, im folgenden System Reset genannt, geloscht. Das pRAM ist ein 
' semipereistentes RAM, das nicht vom Betriebssystem verwaltet wird. Sein Inhalt bleibt bei 
einem SystemReset unverandert und wird in diesem Fall fiir die Initialisierung verwendet. Bei 
einem Stromausfall wird sowohl RAM als pRAM geloscht imd die Datenbank vom FEPROM 
restauriert, 

Damit die Performanz beim Abspeichem der persistenten Daten akzeptabel ist, verwenden 
vni ein pRAM als Zwischenstation fiir die Datenbank. Viele Embedded Systeme garantieren 
eine schnelle Antwortzeit, die beispielsweise eine Transaktionszeit kleiner einer Sekunde 
erfordem. Eine Transaktion setzt sich aus ihrer Ausfuhnmgs- und Conunit-Phase zusanmien, 
wobei die Commit-Phase nur einen Bruchteil der gesamten Transaktionszeit in Anspruch 
nehmen soUte. Dies schlieBt ein direktes Schreiben der Datenbank ins FEPROM aus, da das 
Loschen und Beschreiben eines 64-KB-Blocks im FEPROM bereits im Sekunden-Bereich 
liegt. Das zeitaufwendige Schreiben der Datenbank ins FEPROM muB losgelost von der 
Transaktion in einem HintergrundsprozeB, dem DBServer, durchgefuhrt werden. 
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AbbiUlimg 7: E>ie Datenbankverwaltung Uber die vetsdiiedenen Sp achetxnedien 

DBControl bietet hier folgende Strategic. Die Applikationsprozesse schreiben am 
Transaktionsende, der Commit-Phase, ihre Anderung im persistenten Objektmodell auf DB 
1. Aus Sicht der Applikation ist damit die Transaktion abgeschlossen und die nachste 
Transaktion kann behandelt werden. Der DBServer-Proze/3 wird benachrichtigt, daB eine 
modifizierte Datenbank in DB 1 vorliegt und kopiert daher DB 1 nach DB 2. Der 
prozeBubergreifende ZugrifF auf DB 1 wird uber eine Semaphore gesteuert. Bevor der 
DBServer das FEPROM beschreiben kann, mufi er die entsprechenden Segmente loschen 
Durch altemierendes Schreiben auf DB3 und DB4 ist aber auch bei einem Stromausfall eine 
gultige Datenbank vorhanden. Ist die Datenbank im FEPROM gespeichert, so uberpnift der 
DBServer zyklisch, ob eine weitere Anderung in DB 1 vorliegt. 

Liegt die GrSBe der Datenbank im Megabyte-Bereich, so ist es sinnvoU nur die geanderten 
Daten zwischen den Datenbanken zu kopieren. Das FEPROM ist in 64 Kbyte Segmente 
aufgeteilt. Eine intelligente Datenbank-Clusterverwaltung kann das Schreiben auf das 
FEPROM optimieren, indem nur geanderte Segmente ins FEPROM geschrieben werden. 
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9 Transaktionen mit Trockenkonfigu ration 

Bei vielen Embedded Systemen lassen sich nicht nur die Konfigurationsdaten persistent 
abspeichem, sondem zusatzlich eine periphere Hardware einstellen. Fiir eine bequeme 
Konfiguration des Gerates konnen Transaktionen zunachst ohne Andening der Hardware 
durchgefuhrt werden. 

Fur diesen Zweck verwaltet die Embedded Software zwei verschiedene Zustande. Im Zustand 
IDLE wird eine Trockenkonfiguration vorgenommen. Das bedeutet, dafi nur die Daten 
geandert werden, die genghere Hardware bleibt davon unbeeinfluBt Im Zustand ACTIVE 
wird hingegen bei jeder Ariderung auch die Hardware aktualisiert. Es wird deshalb zwischen 
zwei verschiedenen Konfigurationsstanden unterschieden: der Datenstand kann 
unterschiedlich zur Hardwarekonfiguration sein (siehe Abbildung 8). 



Abbildung 8 zeigt die Zustandsubergange zwischen den Zustanden IDLE und ACTIVE. Beim 
Ubergang von ACTIVE nach IDLE wird der aktuelle Datenbestand als Riickfallposition 
gespeichert (Pfeil 1). AUe folgenden Transaktionen werden ohne Anderung der Hardware 
durchgefuhrt. Der Anwender kann danach entweder die geanderten Daten auf der Hardware 
aktivieren (Pfeil 3) oder wieder die Ruckfallposition einnehmen (Pfeil 2). In beiden Fallen 
geht das Embedded System in den Zustand ACTIVE und die Ruckfallposition wird 
aufgegeben. Die Hardware ist anschlieBend genauso wie der aktuelle Datensatz konfiguriert. 

Dieses Systemverhalten wird auch von dem Datenhaltungskonzept DBControl unterstutzt. Im 
Zustand ACTIVE werden die aktuellen Konfigurationen von DBl nach DB2 und von dort aus 
ins FEPROM geschrieben (siehe Abbildimg 7). Geht das Embedded System in den Zustand 
IDLE, so wird die aktuelle Konfiguration im FEPROM als Ruckfallposition gespeichert. Der 




Abbildung 8: Daten- undHardwarcrustandsdiagramm in IDLE und ACTIVE 
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Datenstand im FEPROM wird zu diesem Zeitpunkt das letzte Mai aktualisiert. Erst beim 
Ubergang m den Zustand ACTIVE wird diese RiickfaUposition aufgegeben. 

Durch diesen Mechanismus hat der Anwender die Moglichkeit, mehrere Transaktionen 
zusammenzufassen. Erst spater wird entschieden, ob diese auch tatsachlich aktiviert werden. 



10 Anlaufverhalten der Datenhank 

Beim Anlauf eines Embedded Systems muB entschieden werden, welche Datenbank von 
welchem Speichermedium fiir den Aufbau des persistenen Objektmodells in den 
Apphkationsprozessen verwendet wird. Das Gerat ist in der Lage, durch Abkopplune 
2wischenDBlundFEPROM(sieheAbbildung7). zweiunterschiedliche 
Konfigurationsstande zu speichem. Deshalb muB festgelegt werden, welche Datenbank bei 
emem Systemhochlauf verwendet wird. AuBerdem gibt es die Moglichkeit, eine Defeult- 
DatenbaiJc zu akfavieren. Sie beinhaltet die Initialwerte des persistenten Objektmodells das 
von den Apphkationsprozessen aufgebaut werden kann. 

DBControI realisiert das Anlaufverhalten folgendermaBen: GrundsStzlich wird bei einem 
Stromausfall unmer aus dem FEPROM gelesen Bei einem System Reset wird anhand des 
ZiKtands des Gerats entsc^eden, ob aus dem pRAM oder aus dem FEPROM gelesen wird Ist 
das Gerat un Zustand IDLE, so wird die RQckfallposition im FEPROM als Datensatz 
venvendet Im Zustand ACTIVE wird DBl aus dem pRAM gelesen, falls hier gerade ein 
gultiger Datensatz gespeichert ist. Moglicherweise ist der System Reset wahrend dem 
commitO ausgelost worden und DB 1 beinhaltet einen inkonsistenten Datensatz, da er nicht 
komplett geschneben wurde. In diesem Fall wird auf das FEPROM zuruckge^ffen Die 
Gultigkeit ernes Datensatzes wird durch ein Valid-Flag gekennzeichnet 

Anlauf von DBControI (siehe Abbildung 8) kopiert nach diesen Kriterien 
t^^f ^ T ^S?^"^.'^ Applikationsprozesse initialisieren anschliefiend 

nTt^ Ji^rT^"^ DBContamer und persistenten C-HHObjekte. Bei der Rekonstruktion der 
Daten mrd auch der Zustand IDLE oder ACTIVE aus dem Datensatz gelesen. Abhangig von 
diesem Zustand wird bemi Hochlauf die periphere Hardware mit demlktuellen ^ 
Konfigmationsstand initialisiert In IDLE behalt die Hardware ihre Konfiguration getrennt 
vom Datensatz des Embedded Systems. Soil der Default-Datensatz aufgeSS w^S sT 
InlSfw^t^ DBContam^ in DBl von der Komponente Anlauf u4ultig geset^^e 
Apphkationsprozesse mussen dann selbstandig ihr Default-Objektmodell auftJuen. 
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11 Layering von DBControl 

Das Datenhaltungssystem DBControl wird von der Applikation als "SimpleService" Schicht 
benutzt. Die Abbildung 3 zeigt das daraus resultierende Layering der Embbeded Software. 
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Abbildung 9: Das Schichtenmodell der Applikation aus Sicht von DBControl 

DBControl laBt sich in mehrere aufeinander aufbauende Komponenten aufteilen. Der 
Persistenzmechanismus wird in der laufenden Applikation fur die Abspeicherung der 
persistenten Daten in DB 1 verwendet. Der DBServer ist ein eigenstandiger ProzeB, der fiir 
die asynchrone Speicherung der Datenbank ins FEPROM uber DB2 verantwortlich ist. Die 
FlashServices umfassen die Treiber fur das FEPROM, die die Lese- und SchreibzugrifFe 
realisieren. Wird beim Anlauf eines Embedded Systems die Datenbank aus dem FEPROM 
restauriert, so benutzt DBControl wdeder die FlashServices. 
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12 Hinweis 

Zusatzliche Bescfe^^^ fur DBControl liegen in Fonn einer Funktionsspezifikation, einer 
Designspezifikation und dem kompletten Sourcecode vor. 
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Patent anspriiche 

1. Datenhaltungssystem fiir persistente Daten 

mit einem Zwischenspeicher (ZST; RAMI, RAM2) , in den sa- 
5 mtliche persistent zu speichernde Daten (MIB) eingeschrieben 
werden, und 

mit einem an den Zwischenspeicher (ZST; RAMI, RAM2) angeschal- 
teten persistenten Speicher (PST; FEPROMl, FEPR0M2), der zwei 
Speichereinheiten oder Speicherbereiche (FEPROMi und FEPR0M2) 
10 aufweist, in denen jeweils die gesamten persistenten Daten 

(MIB) aus dem Zwischenspeichers (ZST; RAMI, RAM2) gespeichert 
werden, 

2. Datenhaltungssystem nach Anspruch 2, 

15 dadurch gekennzeichnet, 

daft die gesamten im Zwischenspeicher (RAMI, RAM2) gespeicher- 
ten persistenten Daten (MIB) abwechselnd jeweils in eine der 
Speichereinheiten oder Speicherbereiche (FEPROMI oder 
FEPR0M2) des persistenten Speichers (PST) eingeschrieben 

2 0 werden. 

3. Datenhaltungssystem nach Anspruch 2, 
dadurch gekennzeichnet, 

daii nur geanderte Datenfolgen abwechselnd in betroffene 
Speichersegmente des persistenten Speichers (PST) einge- 
schrieben werden. 

4. Datenhaltungssystem nach einem der vorhergehenden 
Anspruche, 

30 dadurch gekennzeichnet, 

dali in den Zwischenspeicher (ZST; RAMI, RAM2) nur die persi- 
stenten Daten (MIB) gegebenenf alls inklusive Rekonstruktions- 
daten aus einem ersten Speicher (STl) iibernommen werden, der 
ein Ablaufprogramm und die zugehorigen persistenten Daten 

35 beinhaltet. 



5. Datenhaltungssystem nach Anspruch 5, 
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dadurch gekennzeichnet, 

dali die Daten (MIB) im Zwischenspeicher (ZST; RAMI, RAM2) und 
im permanenten Speicher (PST) platzsparend als Datensequenz 
gespeichert warden. 

6. Datenhaltungssystem nach einem der vorhergehenden 
Anspruche, 

dadurch gekennzeichnet, 

dali mindestens ein weiterer permanenter Speicher (PRST) fiir 
ein Startprogramm und Applikationssof tware einschlieBlich 
Datenbanksoftware vorgesehen ist, mit deren Hilfe aus den im 
permanenten Speicher (PST; EPROMl, EPR0M2) gespeicherten 
persistenten Daten (MIB) automatisch die in den ersten 
Speicher (STl) einzuschreibenden Konf igurationsdaten rekon- 
struiert werden, 

7. Datenhaltungssystem nach einem der vorhergehenden 
Anspruche, 

dadurch gekennzeichnet, 

daB es zur persistenten Konf iguration von Funktionen und/oder 
Eigenschaften eines Terminals (T) und insbesondere von dessen 
Anschluiibaugruppen (TCI, TC2, ...) vorgesehen ist. 

8. Datenhaltungssystem nach einem der vorhergehenden 
Anspruche, 

dadurch gekennzeichnet, 

daii als Zwischenspeicher (ZST) mindestens zwei funktionell in 
Serie geschaltete Schreib-Lese-Speicher (RAMI, RAM2) vorgese- 
hen sind, wobei die im ersten gespeicherten persistenten 
Daten (MIB) in den zweiten werden, so daI5 der erste Schreib- 
Lese-Speicher (RAMI) zur Neueinspeicherung zur Verfugung 
steht, wahrend die persistenten Daten (MIB) aus dem zweiten 
Oder einem weiteren Schreib-Lese-Speicher (RAM2) in den per- 
manenten Speicher (PST) eingeschrieben werden. 



9. Datenhaltungssystem nach einem der vorhergehenden 
Anspruche, 
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dadurch gekennzeichnet, 

daB als permanenter Speicher beschreibbare Flash Eraseable 

Progammable Read Only Memory-Bausteine vorgesehen sind. 

5 10. Datenhaltungssysteiu nach einem der vorhergehenden 
T^spruche, 

dadurch gekennzeichnet, 
daB mehrere Konf igurationen gespeichert warden und eine 
dieser Konf igurationen fiir die harwaremaBige Reailisierung 
10 auswahlbar ist. 



11. Datenhaltungssystein nach einem der vorhergehenden 
Anspruche, 

dadurch gekennzeichnet, 
15 daB zunachst mehre Konf igurationsanderungen nur auf der 
Datenhaltungsseite durchgefuhrt werden und 

daB anschlieBend eine alle Konf igurationsanderungen uitifas- 
sende f unktionsmaBige und/oder hardwaremaBige Anderung im 
Terminal (T) durchgefuhrt wird. 

20 
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Zusammenf assung 

Datenhaltungssystem fiir persistente Daten 

5 Datenhaltungssystem fiir persistente Daten mit einem ersten 

Speicher, aus dem Daten in einen Zwischenspeicher (ZST; RAMI, 
RAM2) eingeschrieben werden, und mit zwei persistenten Spei- 
chern (PST; FEPROMl, FEPR0M2), in die Daten aus dem Zwischen- 
speicher (ZST) ubernommen werden. 



Figur 2 
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